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Abstract 

The “Requirements-to-Design-to-Code” (R2D2C) project at NASA’s Goddard Space Flight Center is based on deriv- 
ing a formal specification expressed in Communicating Sequential Processes (CSP) notation from system require- 
ments supplied in the form of CSP traces. The traces, in turn, are to be extracted from scenarios, a user-friendly 
medium often used to describe the required behavior of computer systems under development. This work, called 
Mise en Scene, defines a new scenario medium (Scenario Notation Language, SNL) suitable for control-dominated 
systems, coupled with a two-stage process for automatic translation of scenarios to a new trace medium (Trace Nota- 
tion Language, TNL) that encompasses CSP traces. Mise en Scene is offered as an initial solution to the problem of 
the scenarios-to-traces “D2” phase of R2D2C. A survey of the “scenario” concept and some case studies are also pro- 
vided. 


1. INTRODUCTION 

Requirements to Design to Code (R2D2C), originated by 
NASA’s Software Engineering Laboratory (Goddard Space 
Flight Center), is a requirements-based approach to system 
engineering. It can also be considered a “model-driven” or 
“model-based” methodology, but with the distinction that the 
model is derived automatically from the requirements instead 
of being created by a human designer. The goal is to make 
requirements the chief documentary artifact, and to derive a 
suitable implementation via several automated and semi-auto- 
mated phases. Another distinctive feature is that the derived 
model is defined using a formal notation. This is useful for 
proving properties about the system and for guaranteeing that 
the derived implementation is functionally equivalent to the 
original requirements, i.e., the implementation is “correct by 
construction.” In order that users having no special training in 
formal methods may freely use R2D2C, the formal model is 
intentionally kept "under the hood” of this methodology. 

R2D2C’s concepts have been described previously 
[FlRR05b, FlRR05a, FlRR05c], and work is underway to 
specify and prototype the various phases of the design flow. 
An overview of the five-phase process is pictured in Figure 1. 
The work described in this Technical Memorandum, called 
Mise en Scene [Car06], is a prototype for phase D2, Traces 


Generator. To place this work in context, we first give an 
overview of R2D2C in Section 2 followed by a problem state- 
ment in Section 3. Section 4 is a survey of related work on 
scenarios. Section 5 describes Mise en Scene in detail, with 
case studies following in Sections 6 and 7. The last two sec- 
tions contain future work and conclusions. 

2, OVERVIEW OF R2D2C 

In Figure 1, the R2D2C design flow begins with a set of 
requirements documents expressed in some manner of textual 
medium. From this set of requirements documents, the D1 
phase, Scenarios Capture — in practice, a project-specific 
translator — creates a set of scenarios in a generic form not 
specific to any project. With the requirements having been 
massaged into a machine-readable, canonical form, the pur- 
pose of the next two phases is to convert them into an equiva- 
lent formal model. 

The fonnal language used is Communicating Sequential 
Processes (CSP), a process algebra often used for modeling 
interprocess synchronization and communication for concur- 
rent systems [Hoa78, Hoa83, SchOO]. The conversion of sce- 
narios to a CSP specification is done in two phases: First, the 
D2 phase (the focus of this memorandum) creates a set of 
CSP traces that express the scenarios in a form compatible 



Fig. 1. Overview of the Requirements-to-Design-to-Code Design Flow 
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with CSP. In normal practice, traces would be derived from a 
CSP specification. However, in this case the D3 phase carries 
out the reverse derivation — inferring a specification from the 
given set of traces. This specification is the intermediate goal 
of the R2D2C design flow. 

The D4 Model Analysis phase is provided to allow the 
specification to be formally analyzed, transformed, and/or 
optimized under a user’s guidance. Finally, the D5 Code Gen- 
eration phase synthesizes compilable source code from the 
CSP specification, or produces an implementation in some 
other suitable project-specific form. 

The scope of this approach is limited to systems whose 
requirements are expressible as “scenarios,” because the 
transformation path from scenarios via traces to a CSP speci- 
fication is theoretically feasible. Before the work described 
herein was commenced, no precise definition of scenarios had 
been set down, nor any specific scenario medium defined for 
R2D2C, The contribution of this work is to present a narrative 
scenario medium inspired by existing scenario-based 
approaches that is suitable for bridging the gap between 
phases D1 and D3. The range of interpretations and 
approaches surveyed in the course of creating this solution is 
summarized in Section 4. 

This new scenario-based approach, dubbed Mise en Scene 
(name explained below), specifically answers two questions: 

• What is the working definition of “scenario ” for the 
R2D2C project? 

• How shall such scenarios be mechanically converted to a 
set of CSP traces? 

The specifics of Mise en Scene’s scenario medium, and 
the mechanics of its scenario-to-traces conversion method, 
will be described after a more precise explanation of the prob- 
lem is given in the next section. 

3. PROBLEM STATEMENT 

The essential problem of designing the D2 phase is that of 
converting scenarios, which admit of a flexible definition, 
into CSP traces, which, in contrast, have a well-established 
definition. Thus, the input and output of the D2 phase can pre- 
liminarily be characterized as follows: 

• A scenario is a sequence of steps that a system is required 
to carry out. 

• A trace is a sequence of events that would be performed by 
a CSP specification during system execution. 

In CSP, an event is an abstract name that can stand for any 
action the system takes or any stimulus that occurs in its envi- 
ronment. Data may optionally be communicated in conjunc- 
tion with the event, in which case it is called a channel. 

Superficially, the conversion of “steps” to “events” should 
be feasible, depending on what the steps encompass and how 
they are expressed. As for the input, R2D2C literature claims 
that the approach is applicable to systems specifiable by sce- 


narios, yet is silent as to a preferred definition of scenarios. 
An important aspect of this work is to provide one. 

Considering the target output, traces in CSP are repre- 
sented as a list of events separated by commas, enclosed 
within a set of angle brackets (< >). A single trace, say <a, b, 
c>, meaning the sequence of the three named events, defines 
one permitted execution of a specification; all permitted exe- 
cutions are given as a set of traces. That set is represented as 
one or more comma-separated traces, enclosed within braces, 
e.g., { <>, <a>, <a,b> }. If a specification is viewed as a state 
machine, its set of traces represents all possible state transi- 
tions. Depending on the specification, an individual trace can 
be an infinite sequence, and the full set of traces may be infi- 
nite in size. 

Trace events provide a kind of “black box” view of system 
execution. For example, CSP processes may specify input or 
output on named channels. Channels are used for interprocess 
communication, and, in an implementation, interface the sys- 
tem with its environment. Specifications may include channel 
I/O events such as sensor ?degrees, meaning “read the 
channel named ‘sensor’ into a variable named ‘degrees’,” and 
sensor! 32, meaning “output 32 on the sensor channel.” 
The corresponding trace event that records the sensor commu- 
nication event where the 32 is stored into degrees would be 
written in the form channel. data: sensor .32. 

A side effect of CSP trace notation is that the direction of 
communication is lost. This is natural, because, while abstract 
processes (which engage in communication and synchroniza- 
tion amongst themselves) are an essential ingredient of CSP 
specifications, process identity disappears at the “black box” 
observation level; all an observer sees is the record of exe- 
cuted events and not the underlying process architecture. 
Stated another way, process specifications may provide clues 
about a possible implementation’s architecture, but traces 
contain no such clues. 

For R2D2C’s design flow, this means that any architec- 
tural clues inherent in the scenarios are, in principle, dis- 
carded in the phase of converting to traces. Furthermore, the 
process architecture inferred by phase D3, and in turn synthe- 
sized into an implementation by D5, may bear no relation to 
an architecture suggested by the input scenarios. On the one 
hand, this may be of no consequence to the R2D2C user, since 
the entire formal model — CSP traces and equivalent specifi- 
cations — is, as mentioned earlier, intentionally kept for inter- 
nal use. On the other hand, throwing away useful data may 
serve to make the job of inferring specifications that much 
harder, and may incline the model inference phase to create 
process architectures that lead to unintuitive implementations. 

Next, the assumptions about the D2 phase’s context are 
stated: The D1 phase, Scenarios Capture, is likely to be appli- 
cation specific. It is assumed that D1 will be capable of out- 
putting “scenarios” using some specified syntax. For 
prototyping work, it is sufficient to implement D1 as a simple 
text editor. 

The D3 Model Inference phase is the heart of the theoreti- 


2 



J. Carter, W.B. Gardner, J.L. Rash, and M.G. Hinchey 


cal work, and may face challenges of computational complex- 
ity due to (a) the potentially enormous volume of traces 
needed to record a non-trivial system’s behavioral require- 
ments, and (b) the extensive processing required by D3’s pro- 
spective theorem prover, ACL2 [KM07]. This work assumes 
that D3 will accept input in the form of conventional CSP 
trace notation, but anticipates there will be room for negotia- 
tion with an eventual D3 design so as to reduce the volume of 
trace input (i.e., notational shortcuts), and help D3 to infer 
features of the target system’s requirements that would other- 
wise be thrown away during their conversion to traces. There- 
fore, this work is not overly concerned with producing a 
definitive and final form of D2 output at this time, since 
adjustments will likely be necessary as the requirements of 
D3 processing are firmed up in future work. 

To summarize the problem, on the “left” input end, the 
output of the D1 phase wants to be in a form that software 
practitioners can recognize as “scenarios.” On the “right” out- 
put end are CSP traces, a highly constrained medium. It 
would be useless to prescribe scenario constructs that cannot 
be converted to traces, therefore this work has focused solely 
on constructs that have a conceptual analog in trace notation. 
A subset of those constructs commonly appearing in scenario- 
based approaches, surveyed in the next section, have been 
adopted. 

4. RELATED WORK ON SCENARIOS 

The term scenario, as will be seen from the citations 
below, is generally used to mean an expressed, exemplary 
action of a proposed or existing system. Scenarios are 
expressed in a range of mediums, with textual and graphic 
being the most prevalent. Scenarios are narrative in form, 
describing a sequence of actions taking place between a sys- 
tem component and its environment. Actions or events in sce- 
narios are fully or partially ordered. While these actions are 
performed sequentially, scenarios often contain “if-else”-style 
conditions and looping constructs. Scenarios have clearly 


defined start and end points, which serve to place them within 
the operational context of the entire system. Scenario end 
points are usually related to a single goal, which may or may 
not be achieved upon termination of the scenario. The sce- 
nario goal may be further decomposed into lesser “sub- 
goals,” achieved through intermediate actions contained 
within the scenario. 

A scenario-based approach is any software engineering or 
requirements engineering methodology making use of scenar- 
ios as a process artifact. Within software engineering, scenar- 
ios arise as usage examples of a proposed system, as system 
test cases, or to describe a design context into which the final 
system must fit. 

Scenarios are frequently used in requirements engineering 
[Car99, FKV91, KS98, Mai98, McG97] as a bridge between 
the realms of developer and customer. Scenarios provide a 
requirements capture medium, often serving as concrete 
examples to elicit further dialog about a proposed system, or 
as a type of “pseudocode” readily understandable by custom- 
ers, written in their language, using customer terminology. 

Different approaches use scenarios to varying degrees, 
ranging from relying on them as a primary design artifact, to 
using them as part of a larger set of practices and techniques. 
Within R2D2C, scenarios are used as a digestible intermedi- 
ate form between diverse kinds of application-specific 
requirements documentation and the rigid structure of formal 
specifications. 

For software and requirements engineering, as well as 
human-computer interaction (HCI), the term is used fre- 
quently, in a variety of contexts. Its exact meaning has been 
the focus of many debates [Cam92a, Cam92b, KK92, Wri92, 
YB92] and usage surveys [GC04, Mai98, RAC+98, Nar92, 
WPJH98, YB87]. Most practitioners do not claim that their 
meaning is "the one true meaning,” but rather an individual 
interpretation that suits their task. Yet despite being a possible 
source of confusion, the term scenario is common, and gener- 
ally employed without any preamble specifying its meaning, 
just as in the existing R2D2C literature. It is accurate to call 
the term “vague in definition and scope” [WPJH98]. 



Fig. 2. General Overview of Mise en Scene and its Elements 
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5. MISE EN SCENE 

As a result of studying the scenarios literature, a particular 
format was devised with the aim of being recognizable to sce- 
nario practitioners while having characteristics that can be 
translated to CSP traces. This design for R2D2C’s D2 phase is 
called Mise en Scene, a term that comes from the field of film 
studies. Literally translating from French gives “putting in the 
scene,” and the term is often used to describe everything visi- 
ble to the camera within a shot, especially elements relevant 
to the narrative of the work. This title was chosen as a wry 
nod to ambiguity in terminology, since “scenario” is similarly 
ambiguous and prone to many interpretations. 

Mise en Scene has four elements, illustrated in block dia- 
gram form in Figure 2, which together accomplish the work 
of the D2 phase: 

1. Scenario Medium — Scenario Notation Language (SNL) 

The medium created for Mise en Scene is a textual, form- 
based notation loosely based on Cockburn’s guidelines for 
effective use cases [CocOl]. Whereas Cockburn states that a 
use case collects a number of scenarios describing related 
behavior, Mise en Scene does not follow this conceptual 
grouping. An SNL scenario is used to describe a single pat- 
tern of required execution in the proposed system. The system 
description may consist of multiple scenarios. 

2. System for Connecting Scenarios — Scenario Glossary 
(SNLGlue) 

A system represented as a collection of scenarios has the 
potential to be extremely disjoint, so as a means of connecting 
common elements in scenarios, a system-wide glossary is 
proposed, allowing a Mise en Scene user to intelligently view 
scenarios interactively, thus showing their interconnections 
with other scenarios. SNLGlue relates to the “data dictionary” 
concept employed in relational database management systems 
and in other system engineering approaches. 

3. Trace Medium — Trace Notation Language (TNL) 

Traces are syntactically simple, and require no specialized 
medium for the Mise en Scene approach. The conventional 
form of traces as used with the Formal Systems CSP tools 
[For] is applied in Mise en Scene, with the addition of an 
XML wrapper that provides the ability to store additional 
optional information used for Mise en Scene and R2D2C inte- 
gration. 

4. Mechanical Transformation Process — SCN2T 

The cornerstone of Mise en Scene is the process by which 
scenarios represented in SNL can be converted to TNL. Sec- 
tion 5.4 lists rules for translating from the SNL scenario 
medium to a set of traces. 


5.1 Scenario Schema 

Following a study of the definitions and uses of “scenar- 
ios” in the literature, a set of attributes common to the major- 
ity of the approaches surveyed was identified. The result, 
listed in Table 1, is similar to Cockburn’s description of a sce- 
nario [CocOl]. The attributes are sorted into two broad cate- 
gories: informational, which likely serve a primarily 

documentary purpose, and functional, which ought to be 
reflected in any synthesized implementation and must there- 
fore be translated to traces. Not all possible attributes were 
selected for Mise en Scene. Those marked with * are present 
in the Mise en Scene scenario schema (defined below) under 
those or similar names, while attributes marked with ** can 
optionally be entered in the Description for documentary pur- 
poses. They were not given dedicated fields for the sake of 
simplicity. Functional attributes that were not amenable to 
translation were not incorporated in the Mise en Scene sce- 
nario schema, but might be added in future work. 


Table 1. Common scenario attributes 


Common Name 
of Attribute 

Description 

Informational Attributes 

Name* 

Title used to identify the scenario. 

Description* 

A textual overview of the actions con- 
tained in, and the actors involved in, the 
scenario. 

Author* 

Who created the scenario. 

Actors* 

Persons or systems involved in carrying 
out the scenario. Actors can be “Pri- 
mary” — the actor who carries out the 
actions of the scenario — or “Second- 
ary” — actors who aid the primary actor. 

Revision 

History** 

A method of tracking changes between 
scenario edits. 

Stakeholders** 

A description or list of persons affected 
by the design of or changes to the sce- 
nario. 

Goals** 

A scenario has one or more goals, which 
are carried out through a set of actions. 

Subgoals** 

Goals may be further decomposed into 
subgoals, which contain their own sets 
of actions. 

Non-Functional 

Requirements** 

Textual documentation containing 
requirements information that cannot be 
readily expressed in a functional form. 
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Table 1. Common scenario attributes (Cont.) 


Common Name 
of Attribute 

Description 

Functional Attributes 

Precondition* 

A description of the state the system 
must be in for a scenario to be eligible 
for execution. 

Triggers* 

The event or events that cause a sce- 
nario to be invoked. 

Flow / Path* 

The sequence of actions that constitutes 
successful execution. 

Alternate Flows / 
Paths* 

Flows of executions invoked by condi- 
tional statements within a scenario. 

Extensions / 
Exceptions* 

Flows of execution used to handle fail- 
ures or other exceptional circumstances. 

Priority 

A classification attribute used to resolve 
non-determinism or scheduling when 
multiple scenarios can be invoked. 

Constraints 

A set of requirements for data or opera- 
tions contained in the scenario; may be 
expressed in a formal syntax or natural 
language. 

Success 

Guarantee 

Conditions that are true upon successful 
termination of a scenario. 

Minimal 

Guarantee 

Conditions that are guaranteed to be 
true, in even the most disastrous failure. 

Safety 

Properties 

A description or list of things that can- 
not happen within the scenario. In per- 
forming any of this list, the scenario 
violates its safety properties, and is con- 
sidered unsafe. 


In the bullets below, each field in the Mise en Scene sce- 
nario schema is defined. Required fields are in bold, the oth- 
ers being optional. Along the way, concepts linking scenario 
attributes and CSP are interspersed. Readers who prefer to see 
concrete examples may wish to scan the case studies in Sec- 
tions 6 and 7 in parallel with this section. 

• ID— A name that uniquely identifies the scenario. Same as 
“Name” in Table 1 . 

• Description — A free-form textual description of the sce- 
nario and what it does. This serves as a comment for read- 
ers in addition to providing text that can be used for 
searching purposes. 

• Author — The names of the author(s), and any other details. 
The following two fields fulfill the purpose of the 


“Actors” attribute in Table 1. The Mise en Scene “compo- 
nent” is similar to the actor/role concept within Cockburn’s 
treatment of use cases [CocOl], as well as to the use-case con- 
cept included in UML [BRJ99, Fow03]. A similar concept is 
seen in other approaches incorporating use cases [SDV96, 
KA06, KKAM06]. The chief difference is that a component is 
allowed to be internal or external to the system, whereas the 
actor/role concept places the actor outside the system. This 
nuance was introduced in an effort to create a concept similar 
to a use case’s actors that better matches the notion of “pro- 
cesses” in CSR As with use-case actors, components may also 
represent other systems or users of the system. 

In scenarios, components are classified as primary or sup- 
plemental. (The term “secondary” was avoided to lessen the 
possible confusion with use-case secondary actors.) 

• Primary Component — The identifier of the component 
that carries out all actions in this scenario. A scenario must 
only have a single component as its primary component, 
which is considered to be the initiator of the scenario. 

• Supplemental Components — Identifiers of components 
referenced within the scenario, with which the primary 
component communicates and synchronizes. A scenario 
may have any number (including 0) of supplemental com- 
ponents. 

In the two following attributes, Precondition and Trigger, 
the concept of a “task” is referenced. The smallest unit of exe- 
cution that components carry out, intended to correspond to a 
CSP event, is called a task, defined by one step in the sce- 
nario’s flow text. A component can only perform a single task 
at a time, though two components may cooperate in perform- 
ing a single task. When tasks in other scenarios are referenced 
for triggers and preconditions, they are qualified with the rele- 
vant component in the form componentlDwtasklD. While 
components and tasks are defined implicitly by mentioning 
them in scenarios, SNL also has statements for explicitly add- 
ing documentation to component names and task IDs. A task 
schema may optionally list the components that are allowed to 
perform it, and this will be enforced by Mise en Scene when 
processing scenario flow text. 

In one sense, the scenarios cause the system to transition 
from state to state by performing individual tasks. Nonethe- 
less, it is worth observing that CSP traces provide an event- 
based formalism, so the notion of “system state” is only 
implied and not explicit, as it would be in a state -based for- 
malism (e.g., Statecharts). The underlying trace semantics 
impose an inherent limitation on the specification of precon- 
ditions: They can only refer to tasks, not to “states.” For 
example, one cannot specify a condition that “The door is 
open”; instead, one specifies that “The OpenDoor task has 
been performed.” If the action is reversible, the door’s state 
could be specified by requiring that the number of OpenDoor 
events exceeds the number of CloseDoor events. 

• Precondition — A partial description of the system state 
required before the scenario can be executed, represented 
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as a set of task identifiers. These tasks must have occurred 
before the scenario can be triggered. The preconditions of 
the system can be empty (specified as “none”), making the 
scenario always ready to be triggered (see next). This kind 
of precondition is fairly simple, and would not allow for 
the situation where a subsequent task neutralizes or 
reverses the referenced task. In future work, it is planned to 
expand preconditions to accept a logical predicate on mul- 
tiple tasks. 

• Trigger — The task ID of the system event that causes the 
scenario flow text to be “executed.” The trigger, which is 
mandatory, in combination with the scenario’s precondi- 
tions (if any) provide a guard: the behavior contained in a 
scenario may only occur after its trigger has passed. The 
most permissive trigger is the task ID System:: start, which 
enables a scenario to be executed at any time during sys- 
tem execution. Once a scenario completes, it must be 
retriggered in order to execute again. 

• Scenario Flow — An ordered set of steps expressed in a 
restricted syntax that specifies the behavior of the scenario 
as actions undertaken by the primary component, and com- 
munication/synchronization with its supplemental compo- 
nents. Cockburn calls this as the “main success scenario,” 
or the case in which "nothing goes wrong” [CocOl]. As 
with use case authoring, the scenario flow should provide 
behavior for the nominal flow of execution, and excep- 
tional circumstances are to be handled by scenario exten- 
sions. The syntax of the scenario flow text, SFT, is detailed 
in Section 5.2. 

• Extensions — Analogous to subroutines or functions in a 
conventional programming language. Scenario extensions 
are written using SFT syntax, and do not contain precondi- 
tions or triggers. Extensions are executed by the SFT 
“extension” directive. Upon completion of an extension, 
control returns to the calling flow, allowing for extensions 
to call other extensions. A scenario may invoke only its 
own extensions, not extensions contained in other scenar- 
ios. A scenario extension is identified by the ScenariolD 
followed by the scope resolution operator (::) and the 
extension identifier. 

Besides the nine attributes listed above, scenarios may 
contain an optional “preamble” field. As with a strongly- 
typed programming language, the purpose is to declare any 
variables that will be referenced by the scenario flow text. See 
Section 5.2.3 for more on variables. 

5.2 Scenario Flow Text (SFT) 


tional-phrase Indirect-object) pattern, as used in much of the 
use case literature [CocOl, RA97, KKAM06], is employed 
with minor additions. SVDPI was chosen as a compromise 
between overly formal syntax and unrestricted natural lan- 
guage. An example is shown in Figure 3. 


1. Probe performs collectjample. 

I t t 

Subject Verb Direct-Object { Prepositional-phrase Indirect-Object } 

111 / 

2. Probe receives new_ph from Sensor. 


Fig. 3. Example of SFT Syntax using SVDPI 
Pattern 

SFT steps may refer to three types of entities — compo- 
nents, tasks, and channels. Components and tasks were intro- 
duced in the previous section. As for channels, just as in CSP, 
they are one-way (simplex) channels with two fixed end- 
points: the producer, who outputs to the channel, and the con- 
sumer who receives input from the channel. Channels have an 
associated set of data types that can be communicated along 
the channel. Operations on channels are considered non-buff- 
ered: a value may only be sent/received if the other endpoint 
is ready to receive/send the message. 

A channel schema lists the data types that it communi- 
cates, and identifies its producer and consumer components; 
its ID is automatically derived from those three attributes. 
Since it is possible to define multiple channels between a pair 
of components, each channel can be augmented with a unique 
alias. 

5.2.1 SFT Step Statements 

The flow text of an SNL scenario is built using a series of 
SFT step statements. Every SFT statement is numbered, to 
provide a unique identifier for each step in the scenario. Spe- 
cific steps of a scenario may be referenced using the follow- 
ing syntax: 

ScenariolD: :Step#N 

Where: 

• ScenariolD is a valid scenario identifier. 

• N is valid step number within the scenario specified. 



Scenario Flow Text, or SFT (pronounced “soft”), is a 
series of lines, each containing syntax known as a step. A step 
contains a task to perform and/or other measures such as con- 
ditionals or communication directives. 

The SFT syntax is based upon simple natural language 
sentences. The SVDPI (Subject Verb Direct-object Preposi- 


Within an extension (discussed below), steps are identified 
as follows: 

ScenariolD: :Extension: : ExtensionID#N 

In practice, the current version of SNL does not use step 
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references. This construct is reserved for future use with pos- 
sible goto and looping steps (see Section 5.2.2). 

The following paragraphs define the various kinds of step 
statements. Literal keywords and symbols are shown in bold 
font. The notation {X|Y|Z} indicates a choice among X, Y, or 
Z. Brackets [X] indicate that X is optional. Note that each step 
is terminated with a period. 

Executional Step. The basic building block of SFT is the 
executional step. It is used to specify that the primary compo- 
nent of a scenario carries out a specific task. An executional 
step is performed in isolation — no communication with 
another component takes place. The syntax of the executional 
step is as follows: 

ComponentID { performs | does | executes } TaskID. 

Where: 

• ComponentID is the identifier of the primary component 
of the scenario containing this step. 

• The verb is one of the three specified synonyms. 

• TaskID is the identifier of a task that is capable of being 
performed by component specified. 

In order to generate an “empty step,” TaskID may be given 
as System: : nothing. The empty step is intended for use 
with conditionals to indicate that in some circumstance, noth- 
ing should be done. 

Communication Step — Sending on an unspecified chan- 
nel. There are two possible communication steps, one for 
sending and one for receiving. In this one, the primary com- 
ponent sends one or more values, in a single transfer event, to 
a supplemental component via a channel. The syntax of the 
send step is as follows: 

ComponentID { sends | transmits | writes | outputs | 
posts | puts } (Valuel,Value2, . .,ValueN-l,ValueN) 
to SupplementalComponent . 

Where: 

• ComponentID is the identifier of the primary component 
of the scenario containing this step. 

• The verb is any of the six specified synonyms. 

• Data values are separated by commas. The enclosing 
parentheses are optional if only a single data value is 
sent. 

• SupplementalComponent is the identifier of a supple- 
mental component with whom the primary component 
can communicate. 

In this version of the sending step, the channel is unspeci- 
fied. If a channel exists that matches the endpoints and speci- 


fied data types, that channel ID is automatically selected. If 
multiple candidates exist, then the channel must be specified 
using the next construct. 

Communication Step — Sending on a specified channel. If 

multiple channels of the same type(s) exist between the same 
endpoints, then the channel alias must be specified. The syn- 
tax is as follows: 

ComponentID { sends | transmits j writes ] outputs | 
posts | puts} (Valuel, Value2, . . , ValueN-l,ValueN) 
to SupplementalComponent via ChannelAlias 

Where: 

• ChannelAlias is the alias of the channel to send on. 

The other syntax elements are identical to the unspecified 
channel send. 

Communication Step — Receiving on an unspecified chan- 
nel. This step is the counterpart of the sending step. Its syntax 
is similar to the sending step, the change being the verb and 
preposition: 

ComponentID {receives | reads | inputs | 
obtains | gets } (Valuel , Value2 , . .,ValueN-l, 

ValueN) from SupplementalComponent. 

If the channel alias must be specified to remove ambiguity, 
the following construct should be used. 

Communication Step — Receiving on a specified channel. 

As with sending, an author can specify the channel for 
transmission as follows: 

ComponentID {receives | reads | inputs | 
obtains | gets } (Valuel , Value2 , . .,ValueN-l, 

ValueN) from SupplementalComponent 
via ChannelAlias. 

Conditional Step. The conditional step allows for one of two 
or more steps to be selected given a condition that is evalu- 
ated. 

if Conditionl then STEPl . 

[else if Condition2 then STEP2 . ] 

[else if CondtionN-1 then STEPN-1.] 
else STEPN. 

Where: 

• Conditionl through ConditionN-1 are conditional 
expressions. 

• STEPl through STEPN are valid steps, as specified 
using SFT syntax. These steps can also contain condi- 
tional steps, thus allowing for nesting of conditionals. 

• Any number of else-if steps may be written. 
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• The last line must contain an else step, which is executed 
if all previous conditions have been evaluated as false. 

In its simplest form, the conditional contains only an “if’ 
step and an “else” step. Each line is evaluated in sequence, 
and the first true statement is executed. If all statements are 
false, the else is executed. 

At present, Mise en Scene supports the following condi- 
tional expressions: 

• Relational: <, <=, ==, >, > = 

• Logical: NOT, AND, OR, XOR 

• Event: TaskID occurred (true if TasklD has occurred 
in the environment of the scenario containing this condi- 
tional) 

Extension Step. This step is used to invoke a scenario exten- 
sion. Scenario extensions are written as separate scenario 
flow fragments, and used to handle exceptional cases. They 
are generally used with conditional steps, or used for organi- 
zational purposes when writing particularly long scenario 
flows. The syntax used to invoke a scenario extension is: 

ComponentID invokes ExtensionID. 

Where: 

• Scenario is the scenario identifier. 

• ExtensionID is an identifier of one of this scenario’s 
extensions. 

Upon completion of the extension, execution returns to the 
scenario flow, continuing with the next step in the flow. 

Arithmetic Step. The arithmetic step is used to manipulate 
scenario variables (described in Section 5.2.3). Here, SFT 
syntax uses the familiar form of the C programming language. 
Although an arithmetic step may be composed of a number of 
statements, it is still considered a single task, making it indi- 
visible. The syntax of the arithmetic step is as follows (in this 
case, the braces, shown in bold, are literal symbols): 

ComponentID performs { assignments } . 

Where: 

• ComponentID is the primary component of the scenario. 

• assignments are one or more assignment statements of 
the form variable = expression, written using the opera- 
tors given below. The semicolon-separated statements 
must be enclosed within a set of braces. 

At present, Mise en Scene provides the following arith- 
metic operators: + (addition), - (subtraction), / (division), * 
(multiplication), and % (modulo). 


Rendezvous Step. The rendezvous step is a modified execu- 
tional step that performs a task synchronized with another 
component. The synchronizing component must appear in the 
scenario’s list of supplemental components. An executional 
step is made to be a rendezvous step by using the “with” key- 
word as follows: 

Step with Component. 

Where: 

• Step is an executional step, written using valid SFT syn- 
tax. 

• Component is a component appearing in the list of sup- 
plemental components for the scenario. 

Note that every communication step is implicitly a rendez- 
vous, so no “with” clause is required. 

An author must be careful in specifying behavior using the 
rendezvous and communication steps, as they may introduce 
deadlock (mutual dependency) into a system. Within R2D2C, 
the D3 and D4 phases will recognize this and alert the author, 
but at present, Mise en Scene (the D2 step) does not diagnose 
this flaw. 

5.2.2 Constructs omitted from SFT 

Originally, a “goto” construct was introduced to allow the 
flow of execution to skip to another step in the scenario. This 
would be used for scenario “looping” (allowing a scenario to 
repeat portions of its behavior indefinitely or until a condition 
was satisfied). However, the construct has been removed from 
this initial version of SFT to avoid the possibility of infinite 
traces. In future work (see Section 8), infinite traces are cited 
as a topic for further exploration, and upon developing a trace 
medium suitable for infinite traces, this construct is likely to 
be reintroduced. 

5.2.3 SFT and Variables 

Mise en Scene allows for variables to exist at two scopes: 
scenario and system. Scenario variables may only be used 
within the scenario that contains them, whereas System Vari- 
ables can be accessed (read-only) by any scenarios within the 
system. The latter allows for parameters to be defined to pro- 
vide system-wide configuration information. Just as CSP has 
no “global variables,” system variables cannot be used to 
communicate between components; channels must be used 
for that purpose. Variables are declared in the system pream- 
ble and scenario preambles. See the Section 6 and Section 7 
case studies for examples of both kinds of preambles. 

Variables are used for channel operations to send or 
receive data, and are necessary for arithmetic and conditional 
syntax. SFT supports the following built-in variable types: 
integer, character, float, string, bit, boolean. Additionally, SFT 
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provides the ability to add custom variable types to a specifi- 
cation in the system preamble. Type information is contained 
in the outgoing trace representation, discussed next. 

5.3 Representing Traces 

The common form of traces as used with the Formal Sys- 
tems CSP tools, FDR and Probe [For], is also utilized in Mise 
en Scene, with the addition of an XML wrapper that associ- 
ates a set of traces with the scenario(s) from which they were 
derived and enables additional information to be passed to the 
next phase of R2D2C alongside the trace set. This is called 
Trace Notation Language (TNL). Additional information 
included in this wrapper are: 

• Scenario Identifier — The ID of the scenario(s) from 
which the set of traces was derived. 

• Component Identifier — The identifier(s) of the system 
component to which this set of traces belongs. 

• Trace Set — The set of traces for the system component, 
represented using the aforementioned trace notation. 

• Types — Definition of types and ranges of variables used 
within this set of traces. 

In order to reduce the volume of traces output, Mise en 
Scene distinguishes between “terminal” traces — those that 
contain all the events recording a system execution from start 
to finish — and "non-terminal” traces. The latter are prefixes 
of a terminal trace, and record any execution short of the end. 
(These definitions rule out infinite traces, which are the sub- 
ject of future work.) From the CSP standpoint, a system’s 
traces must include all possible terminal and non-terminal 
traces, as well as the empty trace < > that represents the sys- 
tem before it does anything. But from the computing stand- 
point, the non-terminal traces are purely redundant and would 
needlessly bulk up the output of the D2 phase. Therefore, the 
SCN2T conversion process generates only the terminal traces 
from a system’s scenarios. Non-terminal traces can be easily 
derived by the D3 phase, should it require them. 

TNL differs from traditional CSP traces in another man- 
ner: variables. As properly defined, channel communication 
events appearing in traces do not contain variables, but only 
containing actual literal values. This may lead to a state space 
explosion, as all combinations of valid data for variables must 
be contained in a process’s traces. To simplify the TNL 
medium, variable place holders have been introduced. These 
place holders have types and value ranges associated with 
them, allowing the complete variable expansion to take place 
at the D3 phase if required. 

Since conditional expressions and arithmetic operations 
cannot be directly expressed in conventional CSP trace nota- 
tion, Mise en Scene encodes this information in the guise of 
trace events. Without the ability to pass these operations to D3 
and later phases, calculations contained in the scenario would 


be lost and not able to be synthesized into an executable 
implementation. 

5.4 Translation Algorithms 

The cornerstone of Mise en Scene is the process by which 
scenarios represented in SNL are translated to TNL. This pro- 
cess is composed of two sub-problems. The first is converting 
individual scenarios into sets of equivalent traces. This is han- 
dled by mapping each line in a scenario to one or more events 
in the generated traces. The second, and larger, problem is 
composing the multiple sets of individual component traces 
into a set of system traces. This is more difficult than single 
scenario to trace translation due to the need to satisfy con- 
straints of multiple scenarios, the possibility of combinatorial 
explosion of traces, and the resulting large data sets. 

This section starts by describing the rules used to translate 
from a single scenario’s SFT to TNL, and then explains how 
to generate traces from scenarios in combination. 

5.4.1 Individual Scenario Translation 

Table 2 lists the elements of SFT syntax by step type, and 
describes the corresponding trace output. Each of these rules 
is applied to every step in a scenario to generate all possible 
traces for that scenario. 


Table 2. Translating steps of SFT 


Step Type 

Effect on Trace Output 

Executional 

States that a system component performs an 
action, thus a single event is appended to the 
trace output. 

Communi- 

cation 

Generates a channel. data event appended to 
the trace output. The channel event contains 
the sender and receiver of the channel as well 
as the data type. 

Conditional 

Creates a set of events equal to the number of 
branches in the conditional statement. Each 
set of events resulting from the conditional 
syntax is appended to every trace preceding 
the conditional statement. The branch can be 
of any step type. 

Extensions 

The traces for an extension invocation are 
generated (according to the steps they con- 
tain) and are appended to the trace output. 

Arithmetic 

Creates an event that denotes the arithmetic 
operation, and the values (variables or con- 
stants) referenced by the operation. 

Rendezvous 

At the scenario level, rendezvous syntax has 
no additional effect on the trace output. 
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5.4.2 Parallel Composition of Scenarios 

After the translation of individual scenarios, and append- 
ing sequentially composed scenarios, comes the task of com- 
bining scenarios in parallel. The trigger attribute determines 
how scenarios combine. If two scenarios share a trigger, they 
are eligible to be executed in parallel. If a scenario is triggered 
by another scenario’s event, the former scenario is composed 
sequentially with the event contained in the latter scenario. 

Parallel execution implies that the order of tasks within 
each individual scenario must be preserved, but the relative 
order between scenarios is not important, except where syn- 
chronization or communication occur. That is, if scenario P 
generates a trace <a,b,c> and scenario Q generates <d,e,f>, 
then when P and Q execute in parallel, any of ten possible 
permutations of <a,b,c,d,e,f> may arise such that a, b, and c, 
and d, e, and f, still occur in their original orders. This is what 
is meant by interleaving traces. If the scenarios share events 
in common for communication or synchronization purposes, 
then the combined trace contains only a single instance of the 
shared events. That is, if P generates <a,x,b> and Q generates 
<d,e,x>, where x is a shared event, the combined traces are 
the four permutations of <a,d,e,x,b> where a, x, and b, and d, 
e, and x, occur in their original orders. 

Precondition and trigger attributes play an important role 
in the creation of system traces. Preconditions filter the set of 
terminal traces to remove all traces that do not contain the 
events specified by the precondition of the scenario. Triggers 
are used to determine the order of scenario execution. 

The generation of system traces (representing the parallel 
composition of scenarios) is carried out using an eight-step 
algorithm: 

• Step 1 — The set of traces for each scenario should be gen- 
erated using the previously discussed rules for each sce- 
nario, and then all eligible scenarios are combined 
sequentially. 

• Step 2 — Create a set of tuples S, whose members have the 
following composition: 

SCN = <ScenarioIDs, ComponentID, Trigger, 
Precondition, Traces, Syncs> 

Populate this set by creating a tuple from each one of the 
scenarios and its derived traces. Each field is explained 
next: 

• ScenarioIDs: The IDs of all scenarios the set of traces 
was derived from. Initially this starts as a single scenario 
ID. 

• ComponentID: The component that executes the traces 
contained in the tuple. 

• Trigger: The trigger of the scenario this tuple was cre- 
ated from. 

• Precondition: The precondition of the scenario this tuple 
was created from. 


• Traces: The set of traces derived from the scenario. 

• Syncs: The list of events that this component rendezvous 
with other components to perform. 

Another tuple is introduced: 

SYSTEMTRACEEVENT = 

ctaskID, ScenarioIDsTriggered> 

This tuple is used to represent events in system traces. 
ScenarioIDsTriggered is a list used to store the IDs of sce- 
narios that this tasklD has already triggered, to prevent 
multiple triggering. These tuples are stored in a set, SYS- 
TEM, which is initially empty. 

Step 3 — Concatenate any scenarios triggered by another 
scenario’s Scenario :: success event. Mise en Scene allows 
especially long scenarios to be broken up into several 
smaller scenarios, composed sequentially using Previous- 
Scenario :: success as the trigger of subsequent scenarios. 

This is done as follows: 

1 . Iterate over the set of tuples S, searching for a tuple T 
that contains a trigger of X::success where X is a sce- 
nario. 

2. Locate scenario X’s tuple in S. 

3. Append all the traces of T to all of the traces for X. 
Append the ScenarioIDs of T to the scenarios IDs of 
X. Make the Syncs of X equal to the union of the 
Syncs for X and T. 

4. Remove T from S. 

5. Repeat steps 1-4 until no more success triggers are 
found. 

Step 4 — Select a scenario that is eligible to run at system 
start. Locate a scenario R such that its trigger is Sys- 
tem::start. Make the traces contained in SYSTEM equal to 
the traces of R. Remove this tuple R from S. 

Step 5 — If possible, select another tuple R such that its 
trigger is System: :start. Interleave R’s traces with SYS- 
TEM, taking into account any common SYNCs. Remove 
tuple R. Repeat this step until no more System: :start trig- 
gers are found. 

Step 6 — Find the first tuple Q in the set of tuples S with a 
trigger event that has occurred in SYSTEM. Verily that the 
trigger event selected has not already triggered this sce- 
nario. Each individual event in a trace in SYSTEM keeps a 
list of the ScenarioIDs it has triggered. Then do as follows: 

1. Interleave the traces of Q with the traces of SYSTEM, 
between the occurrence of Q’s trigger, and the end of 
SYSTEM or Q being retriggered, whichever occurs 
first. Rendezvous with any SYNCS present in the sys- 
tem. 

2. Store the scenario ID of Q in the event inside the 
traces of SYSTEM that triggered Q. 
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Repeat this step until no more scenarios can be triggered. 

• Step 7 — Using the preconditions of scenarios contained in 
S, and the traces in SYSTEM, prune any traces with events 
occurring before a precondition has been met. By having 
each event in a trace in SYSTEM keep track of scenarios it 
has triggered, the system is able to perform this reduction 
after building the set of system traces, thus simplifying 
step 6. 

• Step 8 — The above steps generate the set of all terminal 
traces, containing all possible interleavings. If non-termi- 
nal traces are needed, calculate all the prefixes of all traces 
contained in SYSTEM, and union this set with SYSTEM. 

A final, optional step is variable expansion. True CSP 
traces do not contain “variable placeholders” like TNL traces 
do; instead, the trace set contains all traces for all possible 
combinations of variables’ values. This expansion is easily 
performed, but omitted from Mise en Scene as it may increase 
the size of the trace set by several orders of magnitude, and is 
likely to be more hindrance than help to the D3 phase. 

As the current conception of Mise en Scene does not allow 
for infinite traces, one is not able to specify two scenarios, A 
and B, that re-trigger each other, creating a ping-pong effect. 
Infinite traces and their effect on system specifications are a 
focus of future work. 

5.5 SNLGlue 


Author ID: GSFC 

Primary Component : PagerAgent 

Supplemental Components: UIAgent , DatabaseAgent 
Preconditions: None 
Trigger : 

UIAgent_PagerAgent_PAGERINFOTYPE_reques t . 
requestinf o 

Preamble : 

{ 

PAGERINFOTYPE requestinfo; 

ANALYSTINFOTYPE analystinfo; 

} 

Scenario Flow: 

1. PagerAgent sends requestinfo to DatabaseAgent 
via QUERY. 

2 . PagerAgent receives analystinfo from 
DatabaseAgent via RESULT. 

3. PagerAgent performs createandS toreMessage . 

Scenario Extensions: None 

The RequestPagerlnfo scenario defines the tasks carried 
out by the PagerAgent to retrieve an analyst’s contact infor- 
mation and page them using said information. The scenario is 
triggered by a request from the UIAgent. 

The traces resulting from the SCN2T translation algorithm 
are: 

< Page r Agen t_Da t abas eAgent_PAGERINFOTYPE_QUERY . r 
equestinf o , 

Da t abase Agen t_Pager Agen t_ANALYSTINFOTYPE_RESULT 
. analystinfo , createandStoreMessage> 


In the scenario-based approaches surveyed, a major diffi- 
culty was connecting, collecting, and categorizing scenarios. 
To assist a scenario’s authors, a scenario editor is envisioned 
possessing automated component and task highlighting, and 
the ability to query the system and obtain a clear view of 
interaction between components. This is the fourth ingredient 
of Mise en Scene, the element that unites the other three 
(SNL, TNL, and SCN2T). SNLGlue is a software tool, rather 
than another language, likely to be added during integration 
with R2D2C. It is seen as being particularly helpful for users 
who wish to dispense with the D1 phase and directly author 
scenarios using SNL. 

6. PREVIOUS CASE STUDIES 

In order to confirm that the expressive capabilities of Mise 
en Scene’s scenario medium are at least sufficient to handle 
the few published R2D2C examples, these were represented 
using SNL. Below is the “Page Analyst” scenario taken from 
the LOGOS/ANTS system [HRR05c], reworked in terms of 
SNL: 

Scenario ID: RequestPagerlnfo 
Scenario Description: Requests the pager 
information for an analyst and sends the request 
to the DatabaseAgent. Presented on pg . 11 of 
NASA/TM — 2 005 — 212774 


SNL versions of the other case studies from existing 
R2D2C publications may be found in Appendix A of [Car06]. 

Since the existing examples were brief and did not exer- 
cise the richness of SNL’s syntactic constructs, a somewhat 
larger control-dominated system was created as a case study. 

7. ROBOT PROBE CASE STUDY 

This example presents a set of scenarios for a robotic 
probe designed to conduct soil surveys. Only the scenarios for 


Relay Satellite 



Robot Probe Control Station 


Fig. 4. System Architecture of Robot Probe 
System. 
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Top View Side View 



Fig. 5. Robot Probe Top and Side Views. 

the probe itself are presented. The probe is controlled by a 
command station component (“Station”). Figure 4 shows an 
overview of the entire system, and Figure 5 is a sketch of the 
probe itself. 

The probe contains two treads both capable of forward and 
backward movement, allowing the probe to turn clockwise, 
turn counter-clockwise, move forward, and move backward, 
as shown in Figure 6. The front of the probe contains a sensor 
that reads the pH and water content of the soil at the probe’s 
current location. The sensor and the two treads are controlled 
by three controllers, shown in Figure 7. The probe receives 
commands from and relays data to the system component Sta- 
tion, not shown. This example presents all permitted interac- 
tions with Station, which is considered to be in the 
environment of Probe. 

The scenarios in this example rely heavily on the exten- 



Fig. 6. Robot Probe Movement Commands 
showing tread directions. 


sion/invoke construct, and also demonstrate the use of 
unnamed channels. 

In the following sections the set of traces for each possible 
Probe instruction is derived. Due to the size of the trace set, it 
is abbreviated. 

7.1 System Preamble 

Shown below is the system preamble for the robot probe 
system. Several custom data types have been added for the 
representation of x,y coordinates, probe commands, pH and 
water sample values, and electromechanical instructions to 
the probe’s treads. 

System: :preamble 

{ 

nametype integer = { - 102 4 . . 1024 } 

nametype string = {0..512} 

nametype character = {0..255} 

nametype float = { -10 000 00 . 00 . . 100000 0 . 0 0 } 

nametype bit = { 0 . . 1 > 

nametype boolean = {0..1} 

nametype COORDINATE = {-1000.. 1000) 

nametype COMMANDTYPE = {0..4} 

nametype DIRECTIONCOMMAND = {0..3} 

nametype PHSAMPLE = {0..8} 

nametype WATERSAMPLE = {0..100} 

nametype TREADDIRECTION = {0..1} 

} 

Fig. 8. System Preamble for Robot Probe. 

Next, the schemas for all components of the Robot Probe 
are given: 

Component ID: Station 

Description: The command station relaying 
directional commands to the probe, and the 
recipient of data collected from the sensor. 

Component ID: Probe 


( ) 



> 

Fig. 7. Robot Probe Internal View of Major 
System Components. 
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Description: A two tread, 'tank-style' robotic 
probe that is controlled remotely by a contol 
station. The probe collects soil samples and 
transmits this data to the control station. 

Component ID: MotorControl 

Description: An integrated controller for the 
probe's two independent treads. Receives 
commands from the probe and send electro- 
mechanical instructions and synchronization 
instructions to each of the probe's treads. 
Component ID: LeftTread 

Description: The tread on the left side of the 
probe, controlled by MotorControl. 

Component ID: RightTread 

Description: The tread on the left side of the 
probe, controlled by MotorControl. 

Component ID: Sensor 

Description: The sensor on the front of the 
probe that collects pH and water data from the 
terrain. Sensor is controlled by the probe, and 
relays data back to the control station. 

Fig. 9. Schemas for Robot Probe components 

Next are a number of scenarios that describe the behavior 
of the robot probe, beginning with probe initialization: 

Scenario ID: RobotStart 

Description: Tasks performed by the robotic 
probe upon system start. 

Author: John Carter 

Primary Component: Probe 
Supplemental Component: Station 
Precondition: None 
Trigger: Sys tern :: s tar t 

Preamble : 

{ 

COORDINATE xloc; 

COORDINATE yloc; 

} 

Scenario Flow: 

1. Probe performs robot_initialize . 

2. Probe sends xloc to Station. 

3. Probe sends yloc to Station. 

4. Probe performs robot_ready. 

Extensions: None 

Fig. 10. Scenario describing Probe initialization 

The following scenario outlines the flow of execution for 
receiving and processing a command from Station: 

Scenario ID: RobotCommand 

Description: The probe receives a command to 
turn, move, or collect a sample from Station and 
executes it. 

Author: John Carter 

Primary Component: Probe 

Supplemental Components: Station, MotorControl, 
Sensor 

Precondition: Probe: :robot_ready 


Trigger: Station :: robo t_command 
Preamble: { 

COMMANDTYPE cmd; 

PHSAMPLE new_ph ; 

WATERSAMPLE new_water; 

} 

Scenario Flow: 

1. Probe receives cmd from Station via command. 

2. if (cmd == 0) Probe invokes Forward. 

else if (cmd == 1) Probe invokes TurnRight . 

else if (cmd == 2) Probe invokes Backward, 

else if (cmd == 3) Probe invokes TurnLeft . 

else Probe invokes CollectData. 

3. Probe performs acknowledged. 

Extension ID: RobotCommand :: Extension :: Forward 
Description: Commands MotorControl to move robot 
forward . 

1. Probe performs ready _move . 

2 . Probe sends 0 to MotorControl . 

3 . Probe performs move_complete with 
MotorControl . 

Extension ID: 

RobotCommand: : Extension: : TurnRight 
Description: Commands MotorControl to turn robot 
CW. 

1. Probe performs ready _move . 

2 . Probe sends 1 to MotorControl . 

3 . Probe performs move_complete with 
MotorControl . . 

Extension ID: RobotCommand :: Extension :: Backward 
Description: Commands MotorControl to move robot 
backward . 

1. Probe performs ready _move . 

2 . Probe sends 2 to MotorControl . 

3 . Probe performs move_complete with 
MotorControl . 

Extension ID: RobotCommand :: Extension :: TurnLeft 
Description: Commands MotorControl to turn robot 
CCW. 

1. Probe performs ready _move . 

2 . Probe sends 3 to MotorControl . 

3 . Probe performs move_complete with 
MotorControl . 

Extension ID: 

RobotCommand: : Extension: : CollectData 
Description: Collects a set of samples (pH and 
water) from the sensor. 

1. Probe performs col lect_sample . 

2. Probe receives new_ph from Sensor. 

3. Probe receives new_water from Sensor. 

4. Probe sends new_ph to Station. 

5. Probe sends new_water to Station. 

6. Probe performs sample_done with Sensor. 

Fig. 11. Scenario showing Probe processing a 
command from Station 

The following scenario collects and forwards data: 

Scenario ID: Sensor_Collect 

Description: Collects a pH and water sample from 
the soil at current location. 
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Primary Component: Sensor 
Supplemental Components: Probe 
Precondition: Probe: : robot_initialize 
Trigger: Probe :: collect_sample 
Preamble: { 

PHSAMPLE ph; 

WATERSAMPLE water; 

} 

Scenario Flow: 

1. Sensor performs collect_ph. 

2. Sensor performs collect_water. 

3. Sensor sends ph to Probe. 

4. Sensor sends water to Probe. 

3. Sensor performs sample_done with Probe. 

Extensions: None 

Fig. 12. Scenario describing the Sensor component 
collecting a sample 

The MoveProbe scenario relays commands from the 
Probe to the independent treads: 

Scenario ID: Move_Probe 

Description: Processes movement commands from 
the probe . 

Primary Component: MotorControl 
Supplemental Component: Probe 
Preconditions: None 
Trigger: Probe :: ready _move 
Preamble : 

{ 

DIRECT I ONCOMMAND direction_cmd ; 

} 

Scenario Flow: 

1. MotorControl performs move_command . 

2 . MotorControl receives direction_cmd from 
Probe . 

3. if ( direct ion_cmd == 0) MotorControl invokes 
move_ahead . 

else if ( direct ion_cmd == 1) MotorControl 
invokes turn_right . 

else if ( direct ion_cmd == 2) MotorControl 
invokes move_back. 

else MotorControl invokes turn_left. 

4. MotorControl performs disengage with 
Lef tTread . 

5. MotorControl performs disengage with 
RightTread . 

6 . MotorControl performs move_complete with 
Probe . 

Extensions : 

Extension ID: Move_Probe : : Extens ion : : move_ahead 
Description: Moves robot probe forward. 

1. MotorControl sends 1 to Lef tTread via LTDIR. 

2. MotorControl sends 1 to RightTread via RTDIR. 

Extension ID: Move_Probe :: Extens ion :: turn_right 
Description: Turns robot probe clockwise. 

1. MotorControl sends 1 to Lef tTread via LTDIR. 

2. MotorControl sends 0 to RightTread via RTDIR. 

Extension ID: Move_Probe :: Extens ion :: move_back 
Description: Moves robot probe backward. 


1. MotorControl sends 0 to LeftTread via LTDIR. 

2. MotorControl sends 0 to RightTread via RTDIR. 

Extension ID: Move_Probe :: Extens ion :: turn_lef t 
Description: Moves robot probe counter- 
clockwise . 

1. MotorControl sends 0 to LeftTread via LTDIR. 

2. MotorControl sends 1 to RightTread via RTDIR. 
Scenario description of the MotorControl. 

Fig. 13. Scenario for the MotorControl 

Finally, the scenarios describing the behavior for one of 
the independent treads are presented. The behavior between 
the two scenarios is similar, hence only of the two treads is 
included: 

Scenario ID: Lef tTread_Movement 

Description: Controls the left tread on a tank- 
style robot. 

Primary Component: LeftTread 
Supplemental Components: MotorControl, 

RightTread 

Precondition: Probe: : robot_initialize 
Trigger: MotorControl : move_command 

Preamble : 

{ 

TREADDIRECTION Indirection; 

} 

Scenario Flow: 

Trigger: MotorControl : move_command 

1. LeftTread receives lt_direction from 
MotorControl via LTDIR. 

2. if ( 1 t_direction == 1) LeftTread performs 
1 t_set forward . 

else LeftTread performs 1 t_setbackward . 

3 . LeftTread performs direc tion_engage with 
RightTread . 

4. LeftTread performs move with RightTread. 

5. LeftTread performs disengage with 
MotorControl . 

Extensions: None 

Scenario for the behavior of the probe's left 
tread . 

Fig. 14. Scenario for the Probe’s left tread 

Next we perform the translation of all individual traces. 

7.2 Individual Scenario Traces 

The trace resulting from translating RobotStart is: 

terminal traces (Probe) = { 

<robot_initialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready> } 

The traces resulting from the RobotCommand scenario 
and its extensions are: 

terminal traces (Probe) = { 

<Stat ion_Probe_COMMANDTYPE . cmd , op_equal . cmd .0.1 


14 



J. Carter, W.B. Gardner, J.L. Rash, and M.G. Hinchey 


, ready_move , Probe_MotorControl_DIRECTIONCOMMAND 
. 0 , move_complete , acknowledged> , 

<Stat ion_Probe_COMMANDTYPE . cmd , op_equal . cmd .1.1 
, ready_move , Probe_MotorControl_DIRECTIONCOMMAND 
. 1 , move_complete , acknowledged> , 

<Stat ion_Probe_COMMANDTYPE . cmd , op_equal . cmd .2.1 
, ready_move , Probe_MotorControl_DIRECTIONCOMMAND 
. 2 , move_complete , acknowledged> , 

<Stat ion_Probe_COMMANDTYPE . cmd , op_equal . cmd .3.1 
, ready_move , Probe_MotorControl_DIRECTIONCOMMAND 
. 3 , move_complete , acknowledged> , 

<Stat ion_Probe_COMMANDTYPE . cmd , op_equal . cmd .4.1 
, collect_sample , Sensor_Probe_PHSAMPLE . new_ph, Se 
nsor_Probe_WATERSAMPLE . new_water , 

Probe_S tat ion_PHS AMPLE . new_ph , Probe_Station_WAT 
ERSAMPLE . new_water , sample_done , acknowledged> 

} 

The traces of the Sensor resulting from the SensorCollect 
scenario are: 

terminal traces (SensorCollect) = { 

<collect_ph, collect_water , Sensor_Probe_PHSAMPLE 
. ph , Sensor_Probe_WATERS AMPLE . water , sample_done> 

} 

The traces of the MotorControl, created from the 
MoveProbe scenario: 

terminal traces (MoveProbe) = { 

<move_command, Probe_MotorControl_DIRECTIONCOMMA 
ND . direct ion_cmd , op_equal . direct ion_cmd .0.1, Mot 
orControl_Lef tTread_TREADDIRECTION_LTDIR . 1 , Moto 
rControl_RightTread_TREADDIRECTION_TRDIR . 1 , dise 
ngage , disengage , move_complete> , 

<move_command, Probe_MotorControl_DIRECTIONCOMMA 
ND . direct ion_cmd , op_equal . direct ion_cmd .0.2, Mot 
orControl_Lef tTread_TREADDIRECTION_LTDIR . 1 , Moto 
rControl_RightTread_TREADDIRECTION_TRDIR . 0 , dise 
ngage , disengage , move_complete> , 

<move_command, Probe_MotorControl_DIRECTIONCOMMA 
ND . direct ion_cmd , op_equal . direct ion_cmd .0.3, Mot 
orControl_Lef tTread_TREADDIRECTION_LTDIR . 0 , Moto 
rControl_RightTread_TREADDIRECTION_TRDIR . 0 , dise 
ngage , disengage , move_complete> , 

<move_command, Probe_MotorControl_DIRECTIONCOMMA 
ND . direct ion_cmd , op_equal . direct ion_cmd .0.4, Mot 
orControl_Lef tTread_TREADDIRECTION_LTDIR . 0 , Moto 
rControl_RightTread_TREADDIRECTION_TRDIR . 1 , dise 
ngage , disengage , move_complete> } 

The traces from MotorControl are: 

terminal traces (Lef tTread_Movement ) = { 

<MotorControl_Lef tTread_TREADDIRECTION_LTDIR . It 
_di recti on , op_equal . 1 t_di recti on .1.1, lt_set f orw 
ard , direction_engage , move , dis engage > 
<MotorControl_Lef tTread_TREADDIRECTION_LTDIR . It 
_di recti on , op_equal . 1 t_di recti on .0.1, lt_setback 
ward, direction_engage , move , disengage> } 


terminal traces ( RightTread_Movement ) = { 
<MotorControl_RightTread_TREADDIRECTION_RTDIR . r 
t_di recti on , op_equal . rt_di recti on .1.1, rt_set f or 
ward, direct ion_engage , move , disengage> 
<MotorControl_RightTread_TREADDIRECTION_RTDIR . r 
t_di recti on , op_equal . rt_di recti on .0.1, rt_setbac 
kward , direc tion_engage , move , dis engage > } 

7.3 System Traces 

Next, individual traces of each Probe component are com- 
bined into a set of traces representing the behavior of the 
entire system. Recall that Station is considered part of the 
environment of the Probe, so all possible interactions with 
Station must be included. 

After the system executes System:: start, only one scenario 
is eligible to run, RobotStart, so begin with its trace: 

traces (System) = { 

<robot_initialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready . . .> 

} 

After executing this series of events, no more scenarios 
can execute, due to the RobotCommand triggering on Sta- 
tion: :robot_command. By decoupling Station from this sys- 
tem for the purposes of this example, it is assumed that the 
Station performs this immediately after robot ready. This 
allows the example to incorporate the set of traces arising 
from RobotCommand, and these are appended to the previous 
trace, along the set of possible commands originating from 
Station: 

traces (System) = { 

<robot_initialize , Probe_S tation_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .0.1, ready_move , Probe_MotorControl_DIRECTI 
ONCOMMAND . 0 , move_compl e t e , acknowledged . . . > , 

<robot_initialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .1.1, ready_move , Probe_MotorControl_DIRECTI 
ONCOMMAND . 1 , move_compl e t e , acknowledged . . . > , 

<robot_initialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .2.1, ready_move , Probe_MotorControl_DIRECTI 
ONCOMMAND . 2 , move_compl e t e , acknowledged . . . > , 

<robot_initialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .3.1, ready_move , Probe_MotorControl_DIRECTI 
ONCOMMAND . 3 , move_compl e t e , acknowledged . . . > , 

<robot_initialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, <Station_Probe_COMMANDTYPE . cmd, op_equ 
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al . cmd .4.1, col lect_sample , Sensor_Probe_PHS AMPLE 
. new_ph, Sensor_Probe_WATERSAMPLE . new_water , 

Pr obe_S tat ion_PHS AMPLE . new_ph , Probe_Station_WAT 
ERSAMPLE . new_water , sample_done , acknowledged . . .> 

} 

Next, Sensor’s traces are incorporated, which are only 
appended to the last traces in the previous set, as it shows the 
flow of execution when Station requests a sample. After 
inserting Sensor’s events between Probe and Sensor’s rendez- 
vous, the trace set becomes: 

traces (System) = { 

<robot_initialize , Probe_Stat ion_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .0.1, ready_move , Probe_MotorControl_DIRECTI 
ONCOMMAND . 0 , move_compl e t e , acknowledged . . . > , 

<robot_ini tialize , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .1.1, ready_move , Probe_MotorControl_DIRECTI 
ONCOMMAND . 1 , move_complete , acknowledged . . .>, 

<robot_ini tialize , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .2.1, ready_move , Probe_MotorControl_DIRECTI 
ONCOMMAND . 2 , move_complete , acknowledged . . .>, 

<robot_ini tialize , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .3.1, ready_move , Probe_MotorControl_DIRECTI 
ONCOMMAND . 3 , move_complete , acknowledged . . .>, 

<robot_ini tialize , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, <Stat ion_Probe_COMMANDTYPE . cmd, 
op_equal . cmd .4.1, col lect_s ample , 

collect_ph, collect_water , Sens or_Probe_PHS AMPLE . 
new_ph , 

Sensor_Probe_WATERSAMPLE . new_water , Probe_Statio 
n_PHSAMPLE . new_ph , Probe_Stat ion_WATERSAMPLE . new 
_water , sample_done , acknowledged . . .> } 

Next, the traces of MotorControl are incorporated into 
the first four traces of the previous set, which represent the 
move commands: 

traces (System) = { 

<robot_ini tialize , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .0.1, ready_move , move_command, Probe_MotorCo 
ntrol_DIRECTIONCOMMAND . 0 , 

Mo torControl_Lef tTread_TREADDIRECTION_LTDIR . 1 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 1 , 
disengage, disengage, move_complete , 
acknowledged. . .>, 

<robot_ini tialize , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 


t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .1.1, ready_move , move_command , Probe_MotorCo 
ntrol_DI RECTI ONCOMMAND . 1 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR . 1 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 0 , 
disengage, disengage, move_complete , 
acknowledged. . .>, 

<robot_ini tialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .2.1, ready_move , move_command , Probe_MotorCo 
ntrol_D I RECTI ONCOMMAND . 2 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR . 0 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 0 , 
disengage, disengage, 
move_complete , acknowledged . . . >, 

<robot_ini tialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .3.1, ready_move , move_command , Probe_MotorCo 
ntrol_DI RECTI ONCOMMAND . 3 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR . 0 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR. 1 , 
disengage, disengage, 
move_complete , acknowledged . . .>, 

<robot_ini tialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, <Stat ion_Probe_COMMANDTYPE . cmd, 
op_equal . cmd .4.1, collect_s ample , 

collect_ph, col lec t_water , Sens or_Probe_PHS AMPLE . 
new_ph , 

Sensor_Probe_WATERSAMPLE . new_water , Probe_Stat io 
n_PHSAMPLE . new_ph , Probe_Station_WATERSAMPLE . new 
_water , sample_done , acknowledged . . .> } 

Finally, the events of the left and right treads are added. 
First, the interleavings between the LeftTread and RightTread 
are performed. All of the events in their traces are rendezvous, 
except for ltsetforward, ltsetbackward, rtsetforward, 
rt_setbackward. Each of the movements (first four traces) in 
the above set, uses one of lt_ and rt_. The order in which these 
events occur is arbitrary, since the treads engage, move, and 
disengage together. From this, add the two possible interleav- 
ings for each, and arrive at: 

traces (System) = { 

<robot_ini tialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .0.1, ready_move , move_command , Probe_MotorCo 
ntrol_DI RECTI ONCOMMAND . 0 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR . 1 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR. 1 , 
lt_setf orward, rt_setf oward, direct ion_engage , 
move, disengage, disengage, move_complete , 
acknowledged> , 

<robot_ini tialize , Probe_Station_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE .yloc , robot_ready, robo 
t_command, Stat ion_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .1.1, ready_move , move_command , Probe_MotorCo 
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ntrol_DIRECTIONCOMMAND . 1 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR . 1 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 0 , 
lt_setf orward, rt_setbackward, 

direction_engage , move, disengage, disengage, 
move_complete , acknowledged> , 

<robot_ini t iali ze , Probe_Stat ion_COORDINATE . xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Station_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .2.1, ready _move , move_command, Probe_MotorCo 
ntrol_DIRECTIONCOMMAND . 2 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR. 0 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 0 , 
lt_setbackward, rt_setbackward, 
direction_engage , move, disengage, disengage, 
move_complete , acknowledged> , 

<robot_ini t iali ze , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Station_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .3.1, ready _move , move_command, Probe_MotorCo 
ntrol_DIRECTIONCOMMAND . 3 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR. 0 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 1 , 
lt_setbackward, rt_setf orward, 

direction_engage , move, disengage, disengage, 
move_complete , acknowledged> , 

<robot_ini t iali ze , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Station_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .0.1, ready _move , move_command, Probe_MotorCo 
ntrol_DIRECTIONCOMMAND . 0 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR . 1 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 1 , 
rt_setf orward, lt_setf oward, direction_engage , 
move, disengage, disengage, move_complete, 
acknowledged> , 

<robot_ini t iali ze , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Station_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .1.1, ready _move , move_command, Probe_MotorCo 
ntrol_DIRECTIONCOMMAND . 1 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR. 1 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 0 , 
lt_setf orward, rt_setbackward, 

direction_engage , move, disengage, disengage, 
move_complete , acknowledged> , 

<robot_ini t iali ze , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 
t_command, Station_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .2.1, ready _move , move_command, Probe_MotorCo 
ntrol_DIRECTIONCOMMAND . 2 , 

MotorControl_Lef tTread_TREADDIRECTION_LTDIR . 0 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 0 , 
rt_setbackward , lt_setbackward, 
direction_engage , move, disengage, disengage, 
move_complete , acknowledged> , 

<robot_ini t iali ze , Probe_Stat ion_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_ready , robo 


t_command, Station_Probe_COMMANDTYPE . cmd, op_equa 
1 . cmd .3.1, ready _move , move_command , Probe_MotorCo 
ntrol_DIRECTIONCOMMAND . 3 , 

MotorControl_Lef tTr ead_TREADDIRECTION_LTDIR . 0 , 
MotorControl_RightTread_TREADDIRECTION_TRDIR . 1 , 
rt_setbackward, lt_setf oward, direction_engage , 
move, disengage, disengage, 
move_complete , acknowledged> , 

<robot_initialize , Probe_Station_COORDINATE .xloc 
, Probe_Stat ion_COORDINATE . yloc , robot_r eady , robo 
t_command, <Station_Probe_COMMANDTYPE . cmd , 
op_equal . cmd .4.1, col lec t_s ample , 

col lec t_ph , col lec t_wat er , Sensor_Probe_PHS AMPLE . 
new_ph , 

Sensor_Probe_WATERSAMPLE . new_water , Probe_Statio 
n_PHSAMPLE . new_ph , Probe_Station_WATERSAMPLE . new 
_water , sample_done , acknowledged> } 

The listing of the above traces is tedious, but serves to 
illustrate the translation algorithm at work on the case study’s 
scenarios. 

8. FUTURE WORK 

The largest open problem with respect to SCN2T is the 
issue of infinite traces. There may be a need for “while”-style 
looping within the scenario medium, though the priority of 
this need has yet to be investigated, but infinite traces will be 
a by-product of a looping construct. A number of case studies 
by trial users of Mise en Scene would likely highlight con- 
structs missing from and required in the SNL medium. 

Another area for further development is the implementa- 
tion of a software prototype of SCN2T. This depends largely 
on R2D2C integration. During the course of this work, a num- 
ber of C++ classes and utilities were written to automate cal- 
culations involving traces. These classes were developed with 
an eventual prototype in mind, and should serve as a good 
starting point for building a full implementation. 

Another possible area of application for Mise en Scene is 
the generation of traces for use in formal verification. In order 
to verify trace refinement, a “safety specification” in the form 
of a process, or set of traces that defines all of the permitted 
system behavior, must be created. A tool such as Formal Sys- 
tems’ FDR2 is able to prove that a candidate CSP implemen- 
tation falls within the set of behavior prescribed in the safety 
specification. Traces generated from natural language scenar- 
ios may represent a user-friendly route to creating the needed 
safety specifications. 

R2D2C also includes a shortcut “S” flow whereby scenar- 
ios are converted directly to a subset of CSP, bypassing the 
traces generation and model inference phases. SNL to CSP 
conversion has been attempted, and success has been 
achieved in the area of single scenarios; however, more work 
is needed toward composing CSP processes derived from sce- 
narios to form the top-level system. 
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9. CONCLUSION 

This research addressed the challenge of defining ‘'‘sce- 
nario” in an appropriate manner for the R2D2C project. The 
resulting SNL meets the objectives of (1) being recognizable 
as a “scenario-based approach,” since it is compatible with 
widely surveyed usage, and (2) being translatable to CSP 
traces. Therefore, SNL can play its desired role in the D2 
phase of R2D2C. This was demonstrated by reworking exist- 
ing R2D2C case studies in terms of SNL, and by developing a 
new case study of a control-dominated system (robot probe) 
that would be within the intended scope of R2D2C. 

Furthermore, a challenge of all scenario-based approaches 
is managing the fragmentation resulting from specifying a 
system as a set of loosely connected scenarios. It becomes dif- 
ficult to compose the scenarios into a larger whole. With Mise 
en Scene this has been achieved by limiting the specification 
medium from natural language to structured text, and by 
employing the communication and synchronization paradigm 
of CSP. The resulting scenario medium is suitable for directly 
authoring scenarios for R2D2C even without the aid of a D1 
Scenarios Capture phase, as shown by the robot probe case 
study. 

Finally, Mise en Scene provides the necessary automatic 
means of translating from SNL scenarios to CSP traces, out- 
put in the form of TNL. While the need for some adaptation 
of TNL to an eventual implementation of the D3 Model Infer- 
ence phase must be anticipated, Mise en Scene provides a 
path to go forward into the research on formal model extrac- 
tion from CSP traces, thereby considerably advancing the 
work on R2D2C. 
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